home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d13 / pb_c.arc / TBC2PB < prev   
Encoding:
Text File  |  1991-01-23  |  8.8 KB  |  239 lines
  1.  
  2. Date:  15-Jan-91 15:39 PST
  3. From:  Kurt Inman [71141,2330]
  4. Subj:  pb links tc now
  5.  
  6. Bob,
  7.  
  8. I finally found a way to link TC routines into PB programs!  If you use
  9. the Huge model (code & data segments of any size, including multiple
  10. segments) to compile the C code, it only generates a code segment and
  11. a data segment to the .OBJ file, rather than including the BSS segment
  12. which PB was tripping up on.  Here's how to do it explicitly:
  13.  
  14. 1. Set Options/Compiler/Model to Huge.
  15. 2. Set Options/Compiler/Names/Code names/Segment name to CSEG.
  16. 3. Set Options/Compiler/Names/Code names/Class name to nothing (it
  17.    defaults to '*').
  18. 4. Set Options/Compiler/Names/Data names/Segment name to DSEG.
  19. 5. Set Options/Compiler/Names/Data names/Class name to nothing (it
  20.    defaults to '*').
  21. 6. Compile your code (you don't need to change any Group names or
  22.    BSS names, nor do you have to Options/Linker/Initialize segments).
  23. 7. $LINK the .OBJ module into your PB program as usual.
  24.  
  25. Kurt
  26.  
  27.  
  28.     15-Jan-91  20:19:29
  29. Sb: #Using TC with PB
  30. Fm: Kurt Inman (PowerBASIC) 71141,2330
  31. To: All
  32.  
  33. We've identified a problem which occurs when you attempt to $LINK an .OBJ file
  34. created with Borland's Turbo C compiler into a PowerBASIC program. Many
  35. combinations of Turbo C models and segment names in the .OBJ file will cause PB
  36. to generate either Error 510 (Code requires byte alignment) or Error 509
  37. (Invalid segment name) on the $LINK metastatement.  In fact, the Error 510 is
  38. incorrect in this case, and is generated regardless of whether the code is
  39. byte-aligned or not.
  40.  
  41. The cause of the Error 510/509 is that for all memory models except Huge, Turbo
  42. C creates definitions for three segments in the .OBJ file: code (_TEXT),
  43. initialized data (_DATA), and uninitialized data (_BSS).  Even if you force
  44. Turbo C to use the same name for both data segments, it will still place three
  45. segment definitions in the .OBJ file, causing PowerBASIC to generate Error
  46. 510/509 when it encounters a second data segment definition.
  47.  
  48. The solution is to compile your Turbo C code using the Huge memory model, with
  49. the code segment named CSEG and the data segment named DSEG.  You must also
  50. explicitly tell TC not to generate a class name for either segment.  Using the
  51. Huge model causes TC to generate definitions for only one code and one data
  52. segment, both without group names.  This is the only configuration which fully
  53. conforms to PB's method of linking external routines.
  54.  
  55. Here are the steps to use when compiling your routines with Turbo C version
  56. 2.0.  Borland's Turbo C++ compiler may also generate PB-compatible code if the
  57. corresponding code generation options are enabled.
  58.  
  59. 1. Set Options/Compiler/Model to Huge. 
  60. 2. Set Options/Compiler/Names/Code names/Segment name to CSEG. 
  61. 3. Set Options/Compiler/Names/Code names/Class name to nothing 
  62. (it defaults to '*'). 
  63. 4. Set Options/Compiler/Names/Data names/Segment name to
  64. DSEG. 
  65. 5. Set Options/Compiler/Names/Data names/Class name to nothing (it
  66.    defaults to '*'). 
  67. 6. Compile your code to an .OBJ file (you don't need to
  68. change any Group names or BSS names, nor do you have to 
  69. Options/Linker/Initialize segments). 
  70. 7. $LINK the resulting .OBJ file into your PB program.
  71.  
  72. To: All
  73.  
  74. (continued from previous "Using TC with PB" message)
  75.  
  76. Please let us know if there are any problems with this method.  It works 
  77. in the limited cases that we've tried, but we haven't tested it exhaustively.
  78. We are posting it in an effort to assist those of you who need to link your 
  79. Turbo C routines into PowerBASIC programs.
  80.  
  81. Kurt Inman (PowerBASIC R&D)
  82.  
  83. Sb: #87182-Using TC with PB
  84. Fm: AL MUSELLA 76114,637
  85. To: Kurt Inman (PowerBASIC) 71141,2330
  86.  
  87. Kurt,
  88.   I tried this and got rid of the byte alignment problem, but I am now having
  89. difficulty getting pb to recognize the c functions.  I get error 462"undefined
  90. sub/fn".  I tried declare function  - no help!
  91.   Can you give a short example on how to pass an integer (and maybe a string)
  92. to a c function? Both the c code and pb code.
  93.   BTW - you have to use tcinst to change the names of the groups in TC++,
  94. unlike tc2.0, where you can change them from the enviorment.
  95.                                     Al
  96.  
  97.     16-Jan-91  10:13:32
  98. Sb: #87182-#Using TC with PB
  99. Fm: AL MUSELLA 76114,637
  100. To: Kurt Inman (PowerBASIC) 71141,2330 (X)
  101.  
  102. Kurt,
  103.   I finally got a c .obj to work with pb!   The trick was to turn off the
  104. generate underbars option.  There is still a problem with passing parameters
  105. though, and if you could demonstrate just passing integers back and forth, it
  106. would be a big help.
  107.                                     Al
  108.  
  109. There is 1 Reply.
  110.  
  111.     16-Jan-91  13:55:26
  112. Sb: #87261-Using TC with PB
  113. Fm: Kurt Inman (PowerBASIC) 71141,2330
  114. To: AL MUSELLA 76114,637
  115.  
  116. Al,
  117.  
  118. Here's a simple example of a C function which takes an integer as a parameter,
  119. adds 17 to it, and returns it to the PB program:
  120.  
  121.   TC:
  122.  
  123.   /* compile this to MYCCODE.OBJ as per my last message */
  124.   int pascal DOCALC (int far *pbvar)
  125.   {
  126.   return (*pbvar)+17;
  127.   }
  128.  
  129.   PB:
  130.  
  131.   $link "myccode.obj"
  132.   declare function DOCALC%(integer)
  133.   print DOCALC%(5)     'prints 22 (5+17)
  134.  
  135.  
  136. Some things to note: the C function is declared to use PASCAL calling
  137. conventions (the C function must clean up the stack after the call, not PB),
  138. the parameter PBVAR is declared to be a far pointer to an integer since PB
  139. passes all parameters as far pointers, the function has a return type of INT
  140. which causes the returned integer to be placed in the AX register upon return
  141. (which is what PB expects of an external function that returns an integer), and
  142. PB's DECLARE statement must explicitly specify that the C function is an
  143. integer function which takes an integer as a parameter. I'll put up an example
  144. with strings shortly.
  145.  
  146. Kurt
  147.  
  148.  
  149. Sb: #87307-#Using TC with PB
  150. Fm: Kurt Inman (PowerBASIC) 71141,2330
  151. To: Kurt Inman (PowerBASIC) 71141,2330 (X)
  152.  
  153. Al,
  154.  
  155. Here's a simple example of a C routine which changes the first character of a
  156. PB string which is passed to it as a parameter:
  157.  
  158.   TC:
  159.  
  160.   /* compile as MYCCODE.OBJ as per my earlier message */
  161.  
  162.   #include <dos.h>
  163.  
  164.   void pascal DOSTR(unsigned far *stseg, unsigned far *stofs, int far *stlen)
  165.   {
  166.   char far *stdata;     /* will point to actual string data */
  167.  
  168.   if (*stlen) {         /* if string length > 0 */
  169.     stdata = (char far *) MK_FP(*stseg, *stofs);  /* get data pointer */
  170.     if (stdata)         /* if valid string */
  171.       *stdata = '*';    /* change 1st char of string to '*' */
  172.   }
  173.   }
  174.  
  175.   PB:
  176.  
  177.   $link "myccode.obj"
  178.   declare sub DOSTR(integer,integer,integer)
  179.  
  180.   a$="hello"
  181.   call DOSTR(strseg(a$),strptr(a$),len(a$))   'pass segment/offset/length
  182.   print a$      'will print "*ello"
  183.  
  184. Keep in mind that the C routine must not change the length of the string passed
  185. to it.  Also, this example works for both regular and flex strings. Hope this
  186. helps!
  187.  
  188. Kurt
  189.  
  190. There is 1 Reply.
  191.  
  192.     16-Jan-91  17:19:43
  193. Sb: #87316-#Using TC with PB
  194. Fm: AL MUSELLA 76114,637
  195. To: Kurt Inman (PowerBASIC) 71141,2330 (X)
  196.  
  197. Kurt,
  198.   Thanks very much for the help.  Your sample programs worked fine.
  199. One more question - (although I think this is impossible):
  200.    I was trying to link in the TC BGI routines, to allow my PB programs to use
  201. different fonts.  I used tlib to convert  the needed routines from the graphics
  202. library into .obj files, but the segment names won't work with PB.  Is there
  203. any way to fix that?
  204.   I found a strange way around it, but it's very clutzy:
  205. I set up an interrupt handler (using 60h) in C, which when called from pb using
  206. call interrupt, would print a (constant) string in the correct font.  Now that
  207. you showed me how to pass variables, this may actually be useful!
  208.   One last note:  I made a mistake in my last message: You can set the segment
  209. names from the tc++ enviorment, they are just in a different place on the menu
  210. than in tc.
  211.                     Thanks again,
  212.                     Al
  213. PS:  You should include those 2 examples in the next edition of the manual for
  214. PB!
  215.  
  216. There is 1 Reply.
  217.  
  218.     16-Jan-91  17:53:08
  219. Sb: #87351-Using TC with PB
  220. Fm: Kurt Inman (PowerBASIC) 71141,2330
  221. To: AL MUSELLA 76114,637
  222.  
  223. Al,
  224.  
  225. I think the only way around the problem with the BGI segment names would be to
  226. attempt to directly modify the .OBJ files, in order to change the names to
  227. something that PB could accept.  That would be very messy and may not even be
  228. possible depending on the lengths of the names used, etc. Maybe PB will be able
  229. to handle more segment names in the future, or we or some third party will
  230. develop a graphics library for PB similar to BGI.  For now, though, I don't see
  231. any way around the problem, short of a real kludge.
  232.  
  233. I think we will put the C examples in the next manual (or at least the next
  234. README file) -- that's a good idea!
  235.  
  236. Kurt
  237.  
  238.  
  239.